Bus arbitration system

ABSTRACT

A circuit arrangement for bus arbitration alters the sequence in which device requests are arbitrated with respect to each other and to a previous arbitration sequence. To this end, an arbiter grants access to a first group of devices according to a predetermined sequence. The arbiter then automatically alters the sequence for a second group of devices, granting access to the bus for the second group according to the altered sequence. These features allow the order in which the arbiter sequences through the groups to be automatically varied with respect to each other, diminishing the likelihood of lockout.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.11/021,534, filed on Dec. 23, 2004 by Richard Nicholas(ROC920040096US1), the entire disclosure of which is incorporated byreference herein.

FIELD OF THE INVENTION

The present invention relates generally to a method and system for dataprocessing, and more particularly, to a method and system for busarbitration

BACKGROUND OF THE INVENTION

Computer systems rely on the cooperative interaction of numerous,specialized devices configured to perform a variety of tasks. Typically,the devices interact by reading or writing data to other components inthe system. The successful exchange of data between these components isconsequently vital to the operation of computer systems. Such devicescommonly include a processor, memory and certain peripheral devices,such as mass storage devices, network adapters, display adapters, audioadapters and workstation controllers. These devices are typicallycoupled together using a network of address, data and control lines,commonly referred to as a bus.

One common type of bus is known as the Peripheral Component Interconnect(PCI) bus. Under the PCI bus standard, peripheral components can connectto a PCI bus without the need for glue logic. Thus, PCI provides a busstandard on which high performance peripheral devices, such as graphicsdevices, control panels, tape drives, as well as optical and hard diskdrives, can be coupled to a processor. Bus standards more particularlyrefer to an independent set of protocols, or rules, to conduct datatransfers between the various devices attached to it. Each of theseprotocols is designed into a bus directly and is commonly referred to asthe architecture of the bus.

In a data transfer between different bus architectures, data beingtransferred from the first bus architecture may not be in a form that isusable or intelligible by the receiving second bus architecture.Accordingly, mechanisms have developed for translating data that isrequired to be transferred from one bus architecture to another. Thistranslation mechanism is normally contained in a hardware device in theform of a bus-to-bus bridge, or interface, through which the twodifferent types of buses are connected.

Various bus-to-bus bridges have consequently been designed to match thecommunication protocol of one bus with that of another. These bridgesthus permit system wide communications between devices on differentbuses. For example, a bus-to-bus bridge connecting between a system busand a PCI local bus is called a PCI host bridge. The PCI host bridgecontains all the logic and hardware for translating data communicationsbetween the system bus and the PCI local bus, and ensures that data istransferred between these two buses intelligibly.

A variant of PCI, PCIX, includes a host bridge through which therespective devices may gain access to the bus. The host bridge performswrite back splits, or communicates with the system bus on behalf ofrequesting devices. For instance, an Ethernet device may send a datarequest to a host bridge, which in turn, sends a request for the data toa bus coupled to a memory device storing the data. The bridge thenreceives the data from the memory device and sends it back to theEthernet device. Each bridge usually has posting buffers for temporarybuffering of bus transactions, as these transactions flow through thebridge in both directions.

Multiple devices connected to the different buses must not be allowedaccess via the host bridge to the processor or a local bus at the sametime. Such simultaneous access would confuse computer systems, producingunuseable results. Such confusion is avoided by using a bus arbiter. Abus arbiter controls device access to the bus. Processes used to decidewhen a device may next access the bus via the host bridge isappropriately called bus arbitration. In a bus arbitration scheme, adevice (that may include the host bridge) wanting to use the bus signalsa bus request. In response, the arbiter sends a grant signal to thedevice. After the grant is received, the device may send a request tothe host bridge, prompting the host bridge to access the bus on theother side of the bridge on behalf of the device, i.e., to read or writedata according to the request. The arbiter can then grant to anotherdevice the privilege of having cycles run by the host bridge on itsbehalf.

Arbitration schemes are usually designed to balance two factors whendetermining a sequence for granting the bus via the host bridge. First,each device request typically has a bus priority, and the highestpriority devices are serviced first. Second, to help avoid instanceswhere low priority devices are locked out, most I/O buses such as PCIalso require the arbiter to implement some kind of fairness protocol.The intent of a fairness protocol is to assure that all devices receivea turn on the bus. For instance, one conventional fairness protocol is around robin scheme. Under a round robin fairness protocol, a device thathas just completed a bus operation is not granted access to the bus fora second operation until all other requesting devices have first beengranted access to the bus.

Even though a bus may provide a fairness protocol in the arbiter(s) thatcontrol access to the bus, acceptable access to the bus can beeffectively denied, or locked, to devices. If several or all of thedevices are competing for a single resource, such as system memory, andone of the devices is monopolizing the memory, then another deviceneeding access to the memory may be unable to access the monopolizedresource. This lockout may occur even though the arbiter fairly grantsbus access to all requesting devices. The locked out device is thusunable to capitalize on its bus access allowed by the arbiter, andconsequently receives a retry signal, relegating the device toattempting the transaction at some later time.

More particularly, many buses provide a performance feature usuallyreferred to as retry capability that allows a device to disconnect fromthe bus/host bridge if it is not able to handle the request at thattime. If a target device is not able to handle a request when it occurs,that target can issue a retry, which indicates to the device that issuedthe request on the bus to try again later.

Lockout generally involves interaction between the set of buffers in abridge, the arbiter, and the bus traffic by devices on the bus. Forexample, an arbiter may have a round-robin fairness protocol for fivedevices (Device A, Device B, Device C, Device D and a host bridge). Thehost bridge is assigned the highest priority (priority 0), Device A isassigned the next highest priority (priority 1), Device B is assignedthe next highest priority (priority 2), Device C is assigned the nexthighest priority (priority 3), and Device D is assigned the next highestpriority (priority 4). If all devices ask for the bus at the same time,the fairness protocol will assure that each device gets a chance to tryto utilize the bus. The arbitration priority, in this example, simplydetermines the order in which the devices get a turn to try to utilizethe bus.

When all devices request use of the bus, the host bridge is grantedfirst access, then Devices A to D in sequence. In one scenario underthis scheme, Device A may be running a large amount of reads to systemmemory on the other side of the host bridge. Device A will consequentlyre-request the bus for a new transaction as soon as it completes thecurrent transaction. As such, the host bridge contains four read buffersthat are all currently allocated to Device A reads. Device B maysubsequently want to do some reads. When Device B gets the bus, however,Device B gets a retry because the bridge's buffers are full with DeviceA reads. That is, while the host bridge is acquiring the read data forits four buffers, all other devices that run reads to the host bridgewill receive retries. Eventually, the bridge empties out one of itsbuffers onto the bus, completing one of the read transactions to DeviceA. The host bridge now has one of its four buffers free, but because inthe current scheme Device A will always get the bus after the hostbridge gets the bus because Device A is always requesting the bus.Device A will consequently get the bus next and queue another read tothe host bridge, using the one free buffer slot. Next, the arbiter willgrant the bus to Device B, but again, there will be no buffers free tousem and Device B will receive a retry.

Because the host bridge must get a turn on the bus in order to free up abuffer, and because Device A always gets to run right after the hostbridge, it is clear that Device A will continue to be able to claimevery buffer that frees up, locking out Device B for as long as Device Awants to do reads. A lockout can occur such that each time a specificdevice gets a turn on the bus and is turned away with a retry (orequivalent, depending on the bus type) because other devices keepfilling up the bridge buffers, i.e., saturating the host bridge. A largenumber of retries could result in significant performance losses or evenerrors for the device that is being locked out. For example, the devicebeing locked out may be an ethernet controller that has a requirement todeliver the next packet within a certain period of time, or else thepacket will time out and be considered lost. The ethernet controllercannot deliver the packet in time because it is being locked out fromreading the packet's data from system memory.

The arbiter does not know or care that there are two devices competingfor a common resource. The arbiter does not know the destination of thevarious transactions and how they interrelate. The arbiter is unaware ofwhich devices are retried. As far as the arbiter is concerned, thetransaction was successful in that the device was granted access to runon the bus, even though the device was unable to receive the requesteddata. The arbiter has fulfilled its programmed fairness requirement.

Therefore, what is needed is an improved system for arbitrating deviceaccess to a desired bus.

SUMMARY OF THE INVENTION

The present invention provides a circuit arrangement, method and programproduct configured to improve bus arbitration by, in one aspect,automatically altering the sequence in which device requests arearbitrated with respect to each other and to a previous arbitrationsequence. To this end, features of the present invention include anarbiter configured to grant access to a first group of devices accordingto a predetermined sequence. The arbiter may automatically alter thesequence for a second group of devices, then grant access to the bus forthe second group according to the altered sequence. These features allowthe order in which the arbiter sequences through the groups to beautomatically varied with respect to each other, diminishing thelikelihood of lockout.

Moreover, the variance, or altering of the sequences, may occur afterdiffering periods of time, further minimizing conventional arbitrationproblems. To achieve this benefit, aspects of the invention may includean indicator, such as a pointer used to determine when the altering ofthe sequence should occur. The indicator may be adjusted from time totime in response to an arbitration and/or the expiration of a period oftime. As such, the arbiter may increment and otherwise maintain acounter to keep track of when the indicator should be adjusted. Thearbiter will typically grant access to each request in a group accordingto the appropriate sequence before moving on to a next group.

Another aspect of the invention may include a host bridge configured toaccess the bus on behalf of another requesting device. Features of theinvention thus may apply particularly well in the context of multipledevices attempting to share a common resource, where the shared resourceincludes a device for retrieving data on behalf the multiple devices.

The above and other objects and advantages of the present inventionshall be made apparent from the accompanying drawings and thedescription thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate embodiments of the invention and,together with a general description of the invention given above, andthe detailed description of the embodiments given below, serve toexplain the principles of the invention.

FIG. 1 is a block diagram of a computer system having a local busarchitecture that is configured to automatically alter the sequence inwhich device requests are arbitrated with respect to each other and to aprevious arbitration sequence.

FIG. 2 is a flowchart having steps executable by the arbiter of thesystem of FIG. 1 for managing device access to the bus.

FIG. 3 is a flowchart having a sequence of steps executable by thearbiter of the system of FIG. 1 for determining the sequence used togrant access to the bus for a plurality of requesting devices.

DETAILED DESCRIPTION

Features of the present invention include a circuit arrangement, programproduct and method for arbitrating device access to a bus. Aspects ofthe invention allow the order in which an arbiter sequences through oneor more pools to be automatically varied. Moreover, the variance mayoccur after differing periods of time, further diminishing thelikelihood of lockout. Further aspects of the invention include anarbiter that starts an arbitration period, or tenure, on a clock pulseboundary where one or more requests are pending. Requests are capturedin a pool of current requests during the tenure. These requests areserviced one at a time until the pool of current requests is empty. Atthis point, the arbitration tenure is over, and if any new requests arepending, they are captured into a second pool of current requests, and anew arbitration tenure begins.

During an arbitration tenure, any requests that arrive after the tenurebegan are latched, or stored as pending, but are not allowed into thepool of current requests until the next arbitration tenure begins. Forinstance, if four request inputs are received on a first clock pulse,all four request inputs are put into a current pool. On a second clockpulse, three more requests may be received. These three new requests maybe latched as pending, but do not enter the pool. The arbiter may give agrant to each of the four requesting devices in the current pool, andconsequently removes each request from the pool of current requests.When the last request is removed from the pool of current requests,i.e., the pool is empty, a new arbitration tenure begins, bringing thepreviously latched three requests into a new pool of current requests.These three requests are then serviced one by one in the currentarbitration tenure while subsequent requests become pending and queuedup for the next arbitration tenure.

An aspect of the invention mitigates lockout by varying the order thatrequests are serviced in the pool of current requests. For instance, thearbiter may switch the order in which requests are addressed, e.g., fromascending order to descending order in different arbitration tenures.For example, when a pointer is in the up direction, pending requests maybe serviced in ascending order. When the pointer is alternatively in adown direction, pending requests are serviced in descending order. Thedirection of the pointer may be changed periodically ornon-periodically, and in alternating intervals. For instance, thedirection of the pointer may change every fourth arbitration tenure fora period, then change to every second arbitration tenure for anotherperiod, after which the period may change again. The variance providedby this feature further mitigates instances of lockout. One skilled inthe art will appreciate that multiple other algorithms may be employedto change the direction of the pointer. Such a pointer change willfurther not affect the performance or fairness of the arbiter becauseneither factor is affected by the order in which requests are servicedonce they are inside the pool of current requests. Namely, by varyingthe pointer as discussed herein, instead of by a fixed amount, there isno chance of the pointer always being in the same direction for adevice.

Referring now to the drawings and in particular to FIG. 1, there isdepicted a block diagram of an exemplary computer system 10 having alocal bus consistent with the principles of the present invention. Asshown, a processor 12, a cache memory 13, a memory controller 14, aDynamic Random Access Memory (DRAM) 15 and the arbiter 30 are connectedto a system bus 28 of the computer system 10. Processor 12, cache memory13, memory controller 14 and DRAM 15 are also coupled to a PCI local bus20 of computer system 10 through a host bridge 11. Host bridge 11provides a low latency path through which processor 12 may accessdevices mapped anywhere within bus memory and/or I/O address spaces.Host bridge 11 also provides a high bandwidth path for allowing devicesto access DRAM 15. Host bridge 11 may include various functions such asdata buffering and posting.

Also attaching to local bus 20 may be other devices such as a local-areanetwork (LAN) interface 16 and an expansion bus interface 27. LANinterface 16 is for connecting computer system 10 to a LAN, such asEthernet or Token-Ring. The configuration may also support separatelocal buses under separate host bridges. For example, PCI-to-PCI bridge18 allows local bus 20 to connect to another local bus (not shown),which in turn, may connect to a variety of other devices (also notshown).

Expansion bus interface 27 may couple any other non-PCI peripheralbuses, such as ISA bus, EISA bus, and/or MicroChannel Architecture(MC-A) bus to local bus 20. Typically, various non-PCI peripheraldevices for performing certain basic I/O functions are attached to oneof the peripheral buses. As shown in FIG. 1, local bus 20 may connectvia add-in board connectors to various devices that include an audioadapter board 22, a motion video adapter board 23 and a graphics adapterboard 24.

Bus bridges, such as host bridge 11 and PCI-to-PCI bridge 18, aretypically coupled between a primary bus and a secondary bus. A busbridge enables an access request that initiates on the primary bus tohave a destination on the secondary bus, and enables an access requestthat initiates on the secondary bus to have a destination on the primarybus. For example, after receiving an access request from system bus 28,host bridge 11 will initiate an access request on local bus 20 tocommunicate with one or more of devices 16, 18, 22, 23, 24, or 27.

Device access to each other may be managed by the arbiter 30. In onerespect, the arbiter 30 mitigates the chances of lockout byautomatically varying the sequence in which device requests in a pool 34are serviced. To this end, the arbiter 30 may include a pointer 32 thatindicates the order in which the requests are to be addressed. A counter31 and a preset variable, “x,” may further be used to vary the sequenceof arbitration by automatically switching the direction of the pointer32 after a period of time or number of cycles. Where desired, even thatperiod may be varied to further promote successful access, e.g.,successful read and write operations in the absence of prolongedlockouts. After each request in the current pool 34 has been grantedaccess to local bus 20, the arbiter 30 may create a new pool comprisedof pending requests 35 received and stored while the first tenure wascompleted.

One skilled in the art will appreciate that other devices included insystem 10 may comprise any of a number of different peripheral devicesincluding video accelerators, audio cards, hard or floppy disk drives,Small Computer Systems Interface (SCSI) adaptors and the like. Moreover,the devices shown in FIG. 1 comprise both initiator and targetfunctions, however, one skilled in the art will appreciate that distincttarget and initiator devices may be substituted for the single devicesshown in FIG. 1. Furthermore, while each component in FIG. 1 is shown asbeing a separate device, one skilled in the art will appreciate thatmany such components may be included on one or more microchips perapplication specifications.

System 10, or any subset of components therein, may also be referred tohereinafter as an “apparatus”. It should be recognized that the term“apparatus” may be considered to incorporate various data processingsystems such as computers and other electronic devices, as well asvarious components within such systems, including individual integratedcircuit devices or combinations thereof. Moreover, within an apparatusmay be incorporated one or more logic circuits that circuitarrangements, typically implemented on one or more integrated circuitdevices, and optionally including additional discrete componentsinterfaced therewith.

It should also be recognized that circuit arrangements are typicallydesigned and fabricated at least in part using one or more computer datafiles, referred to herein as hardware definition programs, that definethe layout of the circuit arrangements on integrated circuit devices.The programs are typically generated in a known manner by a design tooland are subsequently used during manufacturing to create the layoutmasks that define the circuit arrangements applied to a semiconductorwafer. Typically, the programs are provided in a predefined format usinga hardware definition language (HDL). Thus, while the invention has andhereinafter will be described in the context of circuit arrangementsimplemented in fully functioning integrated circuit devices, thoseskilled in the art will appreciate that circuit arrangements consistentwith the invention are capable of being distributed as program productsin a variety of forms, and that the invention applies equally regardlessof the particular type of computer readable signal bearing media used toactually carry out the distribution. Examples of computer readablesignal bearing media include but are not limited to recordable typemedia such as volatile and non-volatile memory devices, floppy disks,hard disk drives, CD-ROM's, and DVD's, among others, and transmissiontype media such as digital and analog communications links.

Those skilled in the art will thus recognize that the exemplaryenvironment illustrated in FIG. 1 is not intended to limit the presentinvention. Indeed, those skilled in the art will recognize that otheralternative hardware and/or software environments may be used withoutdeparting from the scope of the invention.

FIG. 2 is a flowchart 40 having steps executable by the arbiter 30 ofthe system 10 of FIG. 1 for managing device access to a bus 28. Featuresof the flowchart 40 allow the arbiter 30 to automatically vary the orderin which requests are sequenced to diminish the likelihood of lockout.More particularly, the arbiter 30 receives at block 42 requests fromdevices 11, 16, 18, 22, 23, 24, and/or 27 to access to the bus 28. Forinstance, an Ethernet device may require and request data stored in aDRAM 115. The arbiter 30 may limit, or lock, at block 44 of FIG. 2 thepool 34 of requests to those current request(s) received at block 42.The current pool comprises an arbiter tenure. Requests received whilecurrent requests remain in the pool 34 will be latched, or temporarilystored. While the timing of the steps of the flowchart 40 may vary asbetween different applications, the requests of block 42 may be receivedwithin a single clock pulse or on different clock pulses.

At block 46 of FIG. 2, the arbiter 30 grants access to the bus for eachrequest according to the sequence dictated by the pointer order. Forinstance, a request corresponding to a first device 16 will be receivedby the host bridge 11. The host bridge 11 may access the bus 28 andperform a read or write function on behalf of the requesting device 16.The host bridge 11 may subsequently return data from the target memory15 to the requesting device 16. The request corresponding to the device16 will then be removed from the pool 34 at block 48. If any requestsremain in the pool at block 50, then the arbiter 30 may grant access tothe bus 28 for the next device having a request in the pool 34 accordingto the scheme dictated by the pointer 32. For instance, the pointer 32may dictate that the arbiter 30 proceed in descending order from therequest of first device 16 in the pool list. One skilled in the art willappreciate that the requesting device may comprise the host bridge 11,itself.

FIG. 3 is a flowchart 60 having a sequence of steps executable by thearbiter 30 of FIG. 1 for determining the sequence used to grant accessto a bus for a plurality of requesting devices. The steps of theflowchart 60 may presume for exemplary purposes that the pointer 32 isinitially preset as “up,” the counter 31 is “0,” and a variable “x” 33is set to 4. One skilled in the art will appreciate, however, that othersettings may alternatively be used per application specifications.Features of the flowchart 60 allow the order in which the arbiter 30sequences through one or more pools 34 to be automatically varied.Moreover, the variance may occur after differing periods of time,further diminishing the likelihood of lockout.

Turning more particularly to block 62 of FIG. 3, the arbiter 30 maydetermine if a device 18 has been granted access to the bus 28. If so,then the arbiter 30 may increment at block 64 the counter 31. As such,the counter 31 may have a value of “1.”

The arbiter 30 may determine at block 66 if the value of the counter 31equals the value of x, i.e., “4.” If not, then the arbiter 30 maycontinue to grant bus access and increment the counter 31 at block 64until the counter 31 increments to a value equal to “x” at block 66.This feature allows the arbiter 30 to continue to sequence throughrequests in one or more tenures for x times.

Where this counter condition is finally satisfied at block 66, thearbiter 30 may determine at block 68 the direction of the pointer 32.For instance, the arbiter 30 may determine at block 68 if the pointer 32is down. If not at block 68, then the arbiter 30 may flip theorientation of the pointer 32, i.e, down, at block 70. This change ofthe pointer's direction will cause the arbiter 30 to sequence throughthe pool 34 in the opposite direction. By varying the order in which therequests are granted access to the bus via the host bridge 11, thechances of a lockout are diminished. The arbiter 30 may furthermorereset the counter 31 to “0” at block 72. As such, the pointer 32 andassociated pointer/sequence direction will be altered on a subsequentcycle beginning back at block 62.

Should the arbiter 30 alternatively determine at block 68 of FIG. 3 thatthe pointer 32 is down, then the arbiter may set the pointer 32 to be upat block 74. This change of the pointer's direction will cause thearbiter 30 to subsequently sequence through the pool 34 in the oppositedirection. The arbiter 30 may additionally reset the counter 31 to 0 atblock 76.

The arbiter 30 may determine at block 78 if the value of x 33 is 4. Ifnot, then the arbiter 30 may change the value of x to 4 at block 80. Ifthe stored value of x 33 is alternatively equal to 4 at block 78, thenthe arbiter 30 may set the value of x 33 to a new value of 2 at block82. This variation may further mitigate the occurrences of lockout. Oneskilled in the art will appreciate that the exemplary values of x mayvary dramatically in different embodiments consistent with theinvention.

In use, a first device has saturated a resource inside the host bridge,but a second device wants to run a cycle using the bus. The host bridgeis ready to complete a transaction for the first device so that it canattend to the others in the pool of requests. For purposes of theexample, the pointer is initially in the up direction. If the hostbridge runs its transaction, then the first requesting device runs andqueues another transaction, and the second device would be retriedbecause the resource was being used. This lockout, as described earlier,will continue to happen as long as the pointer remains in the updirection. But under the scheme afforded by the present invention, thepointer changes direction and will soon be in the down direction. If thepointer is in the down direction after the host bridge runs atransaction, freeing up one of its buffers, then it is the seconddevice, not the first device, which will be granted the bus next andwill be able to queue its transaction to the free buffer in the hostbridge. As such, no lockout occurs. According to an embodimentconsistent with the invention, the duration of the pointer values arevaried in addition to the direction of the pointer in order to eliminatethe possibility that even though the pointer direction is changing,there could still be some repeatable pattern that the system could fallinto whereby the pointer is always in the same direction at just thewrong instant to cause a lockout. Varying the pointer duration slidesthe window of the pointer value with respect to the fixed transactions,avoiding any repeatable relationship between the two.

While the present invention has been illustrated by a description ofvarious embodiments and while these embodiments have been described inconsiderable detail, it is not the intention of the applicants torestrict, or in any way limit, the scope of the appended claims to suchdetail. For instance, while embodiments where discussed in the contextof PCI and PCIX, aspects of the invention may have equal application inthe context of Rapid I/O, and PCI Express, among others. As such,additional advantages and modifications will readily appear to thoseskilled in the art.

The invention in its broader aspects is therefore not limited to thespecific details, representative apparatus and method, and illustrativeexample shown and described. Furthermore, it will be appreciated thatvarious additional modifications may be made to the illustratedembodiments consistent with the invention. It will also be appreciatedthat implementation of the functionality described above, and inparticular, of the specific sequences of operations illustrated in FIGS.2 and 3, within logic circuitry disposed on a memory device, a memorycontroller, and/or other control logic in a memory architecture, wouldbe well within the abilities of one of ordinary skill in the art havingthe benefit of the instant disclosure. Accordingly, departures may bemade from such details without departing from the spirit or scope ofapplicant's general inventive concept.

1. A circuit arrangement comprising arbitration logic configured togrant access to a plurality of devices operatively connected to a bus bygranting bus access to a first group of the plurality of devicesaccording to a predetermined arbitration scheme for determining in whichorder the devices of the first plurality receive access to the busrelative to one another, automatically altering the predeterminedarbitration scheme, and granting access to the bus for a second group ofthe plurality of devices according to the altered arbitration scheme,wherein the arbitration logic is configured to grant access to the busfor the first group of the plurality of devices by grouping requestsassociated with the first group of the plurality of devices to create afirst pool and sequencing through each request of the first poolaccording to the predetermined arbitration scheme until access to thebus has been granted for each request of the first pool, and wherein thearbitration logic is configured to grant access to the bus for thesecond group of the plurality of devices by grouping requests associatedwith the second group of the plurality of devices and receivedsubsequent to the requests of the first pool to create a second pool andsequencing through each request of the second pool according to thealtered arbitration scheme until access to the bus has been granted foreach request of the second pool.
 2. The circuit arrangement of claim 1,further comprising an indicator used to determine the altering of thepredetermined arbitration scheme, wherein the arbitration logic isfurther configured to read the indicator.
 3. The circuit arrangement ofclaim 2, wherein the arbitration logic is further configured to adjustthe indicator.
 4. The circuit arrangement of claim 3, wherein thearbitration logic is further configured to adjust the indicator inresponse to an arbitration performed by the circuit arrangement.
 5. Thecircuit arrangement of claim 3, further comprising a counter, whereinthe arbitration logic is further configured to increment the counter inresponse to at least one of an arbitration, a number of grants and anexpiration of a time period.
 6. The circuit arrangement of claim 5,wherein the arbitration logic is further configured to compare apredetermined value to the counter to determine if the indicator shouldbe adjusted.
 7. The circuit arrangement of claim 3, wherein thearbitration logic is further configured to reset the counter in responseto adjusting the indicator.
 8. The circuit arrangement of claim 1,wherein the plurality of devices includes a host bridge configured toaccess to the bus on behalf of at least one other of the plurality ofdevices.
 9. An apparatus comprising: a bus; a plurality of devicesoperatively connected to the bus; and the circuit arrangement of claim1.